Business Analyst Community & Resources | Modern Analyst

Business Analysis in the Age of AI

Pulkit Singhal — Fri, 01 May 2026 19:24:00 GMT

Business analysis work has become faster and more efficient over the past few years. Requirements are documented more quickly, discussions are summarized sooner, and solution options are produced earlier in the delivery cycle than ever before. Yet many Agile and product teams are discovering an unexpected truth: as delivery accelerates, the importance of human judgment increases rather than diminishes.

The central question facing business analysts today is no longer whether tools and automation belong in analysis work, but where judgment must take precedence. That distinction matters because the most serious failures in delivery rarely come from obvious mistakes. They emerge from reasonable decisions that appear correct at the time and gradually move teams off course.

Where Acceleration Helps and Where It Falls Short

Modern analysis practices are excellent at speeding up work that is inherently mechanical:

Converting discussions into draft requirements
Identifying patterns across large volumes of data
Refining user story language
Summarizing customer or stakeholder feedback

When used well, this removes low‑value effort from the analyst’s workload. When relied upon uncritically, it creates the illusion of progress.

The challenge is not poor quality output. The real risk lies in outputs that are clear, structured, and confident enough to pass surface review, while subtly reinforcing incorrect assumptions. This is where judgment becomes decisive.

Judgment Gap #1: Determining Whether a Requirement Is Worth Building

Clear and complete requirements do not guarantee meaningful outcomes.

In day‑to‑day delivery, analysts encounter familiar patterns:

A requirement addresses a visible symptom rather than the underlying problem
Stakeholders agree on wording but diverge on expected results
A feature meets acceptance criteria yet produces no behavioral change

Experienced analysts pause to ask questions that artifacts alone cannot answer:

What decision or behavior is supposed to change as a result of this work?
If this is delivered perfectly and nothing improves, what are we missing?

Strong analysis is not just about expressing requirements well, but about challenging their intent.

Judgment Gap #2: Interpreting Context That Never Appears in Documentation

Business environments contain layers of context that rarely make it into requirements or datasets:

Organizational dynamics and power structures
Regulatory concerns driving risk‑averse behavior
Legacy failures that shape stakeholder trust
Competing incentives across teams

Analysts recognize these signals not because they are documented, but because they have seen the downstream effects:

Solutions that are functionally correct but poorly adopted
Processes that are bypassed in practice
Reports and dashboards that exist but are ignored

Judgment here is not guesswork. It is pattern recognition developed through exposure to real consequences.

Judgment Gap #3: Recognizing When Clarity Creates False Confidence

Early clarity is often welcomed as momentum. Detailed backlogs, well‑defined flows, and polished models can make teams feel aligned and confident.

Seasoned analysts remain cautious.

They ask whether clarity is reducing uncertainty—or simply hiding it:

Are assumptions being locked in too early?
What would invalidate this design once it is tested?
Are open questions being resolved, or quietly deferred?

Sometimes the most responsible decision is to leave things deliberately unresolved, even when tools and processes encourage premature finalization.

What This Means for Business Analysts

As delivery mechanics become faster, the value of business analysis shifts away from producing artifacts and toward exercising judgment:

Framing the right problems
Interpreting conflicting signals
Evaluating consequences under uncertainty
Challenging assumptions before they harden

These capabilities are not procedural skills. They are developed through experience, reflection, and exposure to real outcomes especially failure.

Closing Thoughts

Modern tools and practices have made business analysis more efficient, but efficiency does not replace responsibility. The most effective analysts are not those who produce the most artifacts in the shortest time. They are the ones who know when clarity is helpful, when it is premature, and when the best contribution is to pause and ask a different question altogether.

That work remains deeply human and central to successful delivery.

Reinventing the Annual Member Survey: A Business Analyst’s Role in Delivering Actionable Insights

Pulkit Singhal — Sun, 25 Jan 2026 02:38:00 GMT

In a competitive and rapidly evolving financial landscape, understanding member needs is vital to maintaining strong relationships and delivering meaningful value. Yet for many institutions, especially those with legacy processes, collecting structured member feedback can be surprisingly underdeveloped. This was the case at the Federal Home Loan Bank of Chicago (FHLBank Chicago), where — despite its extensive engagement with member institutions — the Bank had never before conducted a structured, enterprise-wide Annual Member Survey.

Recognizing the need for a formalized feedback mechanism, the Bank launched an initiative to design and implement its first-ever Annual Member Survey, leveraging Salesforce as the foundational platform. As the Lead Business Analyst, I was responsible for envisioning, architecting, and orchestrating this new capability from the ground up.

This initiative ultimately became a defining example of how strategic business analysis can create net-new organizational capability, not just improve existing processes.

The Challenge: Creating a Strategic Feedback Framework from Scratch

Unlike most process-automation projects, this effort did not begin with an existing workflow to analyze or improve. Instead, the Bank faced a unique challenge:

No prior survey process existed
No historical data or response structures were available to benchmark against
No distribution, tracking, or reporting mechanisms had been established
No governance model existed for how results should be consumed
Stakeholders possessed varying assumptions about what the new survey should accomplish

This meant the project required not only systems expertise but also conceptual design, stakeholder alignment, and strategic framing.

My Role as Lead BA: Designing a New Enterprise Capability

The absence of an existing process meant that Business Analysis would shape the entire direction of the initiative. My responsibilities included defining the business problem, creating the process architecture, establishing data structures, and ensuring Salesforce could support a sustainable and scalable survey model.

1. Establishing the Vision and Framing the Purpose

Through interviews and collaborative workshops with Member Strategy, Sales, Analytics, and Leadership teams, I led discussions to answer foundational questions:

What insights should the Bank gather annually?
How should “member satisfaction” be defined in measurable terms?
What KPIs would create genuine value for leadership?
How should results be tied back to member institutions in Salesforce?

This work produced the Bank’s first Survey Vision and Strategy Framework, guiding all subsequent design decisions.

2. Building the End‑to‑End Survey Workflow in Salesforce

Because no prior workflow existed, I architected a brand‑new process designed around clarity, automation, and scalability:

Designed the survey creation and distribution model
Built logic for survey-to-member linking
Defined the response-collection data structure
Modeled the end‑to‑end visibility lifecycle, including assignment, participation, reminders, and results
Ensured dashboards would give leadership real-time insights

The process not only captured survey responses but also embedded insights directly into the Bank’s member management ecosystem.

3. Translating Ambiguity Into Clear, Actionable Requirements

Given the lack of precedent, requirements had to be derived through deep analysis rather than comparison. I authored:

Detailed user stories
Acceptance criteria
Process maps
Data models
Reporting definitions

This documentation became the foundational blueprint for developers, testers, and end-users — eliminating ambiguity and creating shared understanding.

4. Leading UAT and Validating a New Capability

Because the Bank had never conducted a survey like this, UAT required additional rigor:

I designed test scripts covering every stage of the survey lifecycle
Trained business stakeholders on how to test a process that was entirely new
Triaged defects and clarified user expectations
Ensured the system was intuitive and future-proofed

Through this, the Bank gained confidence not just in the technology, but in the process itself.

5. Supporting Rollout, Adoption, and Governance

Beyond system delivery, I worked closely with:

Member Strategy teams to formalize interpretation of results
Analytics teams to align on scoring and reporting methodologies
Change management teams to ensure smooth onboarding
Salesforce admins to embed long‑term maintainability

This ensured the survey became an annual, repeatable, institution-wide capability—not a one‑off project.

Conclusion: This project shows that Business Analysts are not just process improvers—they are capability creators.By clarifying needs, defining strategy, architecting processes, aligning teams, and ensuring quality, the BA function enabled FHLBank Chicago to establish a powerful new insight mechanism that will shape strategy for years to come.

The Annual Member Survey is now more than a project deliverable.
It is a permanent intelligence asset for the Bank — built on a foundation of Business Analysis leadership.

When Should an Analyst Suggest Using Queues in Integrations?

Andrii Siryi — Tue, 28 Oct 2025 15:43:00 GMT

One of the most underrated skills for a business or system analyst in integration projects is knowing when to recommend a message queue — tools like RabbitMQ, Kafka, or Azure Service Bus.

Let’s be honest: not every integration needs one. But when it does, queues can save your system from chaos.

What Queues Actually Solve

Message queues are not just “another tech buzzword.”
They handle asynchronous communication — meaning systems don’t have to wait for each other to respond.

Example:
Instead of sending an invoice from System A and waiting for System B to confirm,
System A drops the invoice into a queue.
System B picks it up when it’s ready.

Benefits:

Smooth data flow even if one system is slow or offline
Built-in retry and error handling
Better scalability — handle thousands of messages per second
Natural decoupling between systems (less spaghetti logic)

When Analysts Should Recommend Queues
You don’t need a queue for every integration. But consider it when you see these signs:

High volume of transactions — more than a few thousand per hour.
Unstable or external systems — APIs that sometimes fail or have latency issues.
Different processing speeds — one system sends faster than another can receive.
Business-critical data — where you can’t risk data loss or duplication.
Complex workflows — where multiple consumers (systems) need the same event.

When Not to Use Queues

For real-time user interactions (e.g., “show me the balance now”) — queues add delay.
For simple 1:1 synchronous API calls — direct REST is cleaner and faster.
When the team can’t support monitoring (queues need visibility and alerts).

As an analyst, you don’t have to design Kafka topics or RabbitMQ exchanges.
But you should recognize the moment when a queue turns from “technical detail” into a business enabler — ensuring reliability, scalability, and peace of mind for everyone involved.

For Business/System Analysts who work with ERP integrations.

Andrii Siryi — Tue, 28 Oct 2025 15:42:00 GMT

When designing ERP integrations (for AR/AP document flows), Business/System Analysts often face a range of “gotcha” questions — technical, architectural, and sometimes unexpected.
Here are some of the real-world questions I ask clients during the API and ERP connector discovery phase:

What’s the minimum required ERP version to support all AR/AP endpoints?
Could upgrading the ERP version change the API behavior (fields, formats)?
Are there any heavy or slow API methods under load? Recommended workarounds?
Does the ERP provider charge for API calls, or is usage unlimited?
Can we get a list of possible API error codes?
Any record count limits per request? (e.g., max 1000 records in GET)
What type of authentication is used — Basic Auth, OAuth2, or token-based?
What’s the average response time of the API?
Are there any debug/logging tools if something goes wrong with the call?
Any breaking changes in recent patches that could affect us?
Does the API support batch insert/update or only record-by-record?
In what format are dates returned? Full datetime or date-only?
How are balances returned (positive/negative for credit memos)?
Can documents be posted without updating the "last modified" date?
Can an account include multiple subsidiaries? How to filter by them in the API?
Are any API methods planned for deprecation? What will replace them?
Are some API endpoints available only with paid ERP modules or add-ons?
Are some fields or features hidden unless specific ERP configuration settings are enabled?
Does the ERP API return full relational data (e.g., linked documents, GL splits), or do we need extra queries?
How can we detect deleted records if the API doesn’t expose a deleted flag or status?

These questions aren't just technical — they help avoid costly mistakes, failed syncs, or misunderstood logic.

Field Mapping vs. Canonical Data Model — Which One Wins in Integrations?

Andrii Siryi — Tue, 28 Oct 2025 15:39:00 GMT

When building integrations between systems, one of the first architectural choices you’ll face is how to align data between them.
Two main approaches dominate this conversation: direct field mapping and the canonical data model.
Let’s break them down.

Field Mapping: Simple but Fragile

Field mapping means you connect each field from System A directly to a matching field in System B.
It’s fast to implement and easy to visualize:

Example:
“CustomerName” → “ClientFullName”
“InvoiceDate” → “BillingDate”

Pros:

Quick setup for simple integrations
Easier to debug and understand
Great for 1-to-1 integrations

Cons:

Every new system adds complexity — you end up maintaining dozens of mappings
Any field name or format change breaks the flow
Hard to scale beyond a few connections

This approach is fine for small, stable environments — like syncing data between CRM and ERP once a day.

Canonical Data Model: Structured and Scalable

A canonical model introduces a shared, unified data layer — a kind of “translation dictionary” for your enterprise.
Instead of connecting systems directly, each system maps to the canonical schema.

Example:
System A → Canonical Model → System B
“CustomerName” → “Customer.FullName” → “ClientFullName”

Pros:

Greatly simplifies multi-system integrations
Reduces maintenance costs over time
Makes it easier to add or replace systems

Cons:

Requires more design work upfront
May be overkill for small projects
Needs governance and version control

This approach shines in large ecosystems — where data flows across multiple ERPs, CRMs, or custom apps.

So… Which One to Choose?

If you’re connecting two systems and don’t expect frequent schema changes — use field mapping.
But if your integration landscape is growing and you want to reduce long-term pain — invest in a canonical model early.

Think of field mapping as a shortcut, and the canonical model as a foundation.

YAML-Based Story Mapping

Andrii Siryi — Tue, 28 Oct 2025 15:37:00 GMT

System Analysts who work with integration processes should formulate user stories in a way that diverges from the traditional structure. This is primarily due to the need for a more technical and structured description, which allows for the inclusion of integration-specific details.

The user story might need to specify exactly what kind of data should be retrieved via an API, from which system, using what HTTP method, and so on.
Additionally, such user stories can incorporate validation requirements.
For instance, before sending the data to an external system through an API, certain transformations or formatting might be required.

As a result, the structure of a user story in this context tends to differ significantly.

Here’s an example of how a story might look:

story_map:
epic: "Invoice Integration"

user_stories:

id: US001
title: "Obtain AR invoice"
as_a: "Application X"
i_want: "obtain AR invoices from ERP {{X}} via API"
so_that: "I can handle this invoice and send to the client"
source_system: "ERP {{X}}"
target_system: "Application X"
direction: "pull"
api_call:
method: "GET"
endpoint: "/api/invoices"
auth_required: true
id: US002
title: "Validate data"
as_a: "Application X"
i_want: "validate the fields of the received invoice"
so_that: "I don't sync the invoice with errors"
validation:
invoice_number: "required"
invoice_id: "required"
invoice_total_amount: "should be > 0"
invoice_status: "should be 'posted'"
id: US003
title: "Push invoice payment"
as_a: "Application X"
i_want: "push the invoice payment created in Application X to the ERP"
so_that: "the payment is approved in the ERP and synchronized back"
source_system: "Application X"
target_system: "ERP {{X}}"
direction: "push"
api_call:
method: "POST"
endpoint: "/api/payments"
auth_required: true

6 Differences Between Data Exploration and Data Presentation

Zach Gemignani — Wed, 16 Mar 2022 18:55:00 GMT

There are big differences between data exploration versus data presentation. And you need to be aware of these differences as you're creating data stories and data presentations. Let’s start by defining our terms:

Data exploration means the deep-dive analysis of data in search of new insights.
Data presentation means the delivery of data insights to an audience in a form that makes clear the implications.

Your toolbox for data exploration tools is flush with technology solutions such as Tableau, PowerBI, Looker, and Qlik. "Visual analytics" tools give analysts a super-powered version of Excel for dicing data to facilitate the search for valuable insights. Flexibility and breadth of features is critical; the user needs to handle lots of data sources and doesn’t know in which direction she will go with the analysis.

Data presentation is a different class of problem with distinct use cases, goals, and audience needs. Think about the incredible data stories delivered by the The Upshot, Fivethirtyeight, and Bloomberg. These data journalists often demonstrate data presentation at its finest, complete with guided storytelling, compelling visuals, and thoughtful text descriptions. When compared to these examples, it becomes obvious that the best efforts by a data exploration tool cannot deliver high-quality data presentation.

You need a specialized solution if you really want to communicate data in ways that engage your audience. To understand the differences between data exploration and data presentation tools, let me offer six key ways that the activities are fundamentally different.

1. Audience — Who is the data for?

For data exploration, the primary audience is the data analyst herself. She is the person who is both manipulating the data and seeing the results. She needs to work with tight feedback cycles of defining hypotheses, analyzing data, and visualizing results.

For data presentation, the audience is a separate group of end-users, not the author of the analysis. These end-users are often non-analytical, they are on the front-lines of business decision-making, and may difficulty connecting the dots between an analysis and the implications for their job.

2. Message — What do you want to say?

Data exploration is about the journey to find a message in your data. The analyst is trying to put together the pieces of a puzzle.

Data presentation is about sharing the solved puzzle with people who can take action on the insights. Authors of data presentations need to guide an audience through the content with a purpose and point of view.

3. Explanation — What does the data mean?

For the analysts using data exploration tools, the meaning of their analysis can be self-evident. A 1% jump in your conversion metric may represent a big change that changes your marketing tactics. The important challenge for the analysts is to answer why is this happening.

Data presentations carry a heavier burden in explaining the results of analysis. When the audience isn’t as familiar with the data, the data presentation author needs to start with more basic descriptions and context. How do we measure the conversion metric? Is a 1% change a big deal or not? What is the business impact of this change?

4. Visualizations — How do I show the data?

The visualizations for data exploration need to be easy to create and may often show multiple dimensions to unearth complex patterns.

For data presentation, it is important that visualizations be simple and intuitive. The audience doesn’t have the patience to decipher the meaning of a chart. I used to love presenting data in treemaps but found that as a visualization it could seldom stand-alone without a two-minute tutorial to teach new users how to read the content.

5. Goal — What should I do about the insights?

The goal of data exploration is often to ask a better question. The process of finding better questions gets to new insights and a better understanding of how your business works.

Data presentations are about guiding decision-makers to make smarter choices. Much of the learning (through data exploration) should be done, leaving the equally difficult task of communicating the insights and the actions that should result.

In all these ways, data exploration and data presentation are different beasts. This is why we’ve chosen to focus on building the best possible data presentation tool, Juicebox.

6. Interactions — How are data insights created and shared?

Data exploration can be a lonely endeavor: Analysts work on their own to gather data, connect data across silos, and dig into the data to find insights. Data exploration is often a solitary activity that only connects with other people when insights are found and need to be shared. That is, when…

Data presentation is a collaborative, social activity. The value emerges when insights found in data are shared with people who understand the context of the business. The dialogue that emerges is the point, not a failure of the analysis.

Finding the Middle Ground: Data Storytelling

There is something between the extreme ends of data exploration and data presentation. We believe data storytelling lies in this intersection. Data stories aren’t entirely about “telling”, nor are they in the wilderness of “finding”. It is the opportunity to explain the data in a guided, narrative way where message meets exploration.

While there are tools for exploration (e.g. Tableau) and tools for presentation (e.g. PowerPoint), it is only recently that you’ve had the change to bring both together in one solution.

Zach Gemignani (zach.gemignani@juiceanalytics.com)

CEO, co-founder, author at Juice Analytics

www.juiceanalytics.com

Top 10 Mistakes in Requirements Elicitation

Trividh Patel, CBAP — Tue, 27 Apr 2021 05:47:00 GMT

Elicitation involves bringing out or drawing out information. Elicitation is a key task in business analysis as without proper elicitation the requirements for the solution to the business needs cannot be identified.

1. Not understanding underlying business need

Organization’s business environment keeps changing with respect to Customers, Marketplace, Technology and Marketing function. It is these changes in business environment that leads to identification of business needs at the strategic level in terms of problem or opportunity faced by the organization.

Defining business needs is the most important step in business analysis. Without understanding and defining underlying business needs, it would not be possible to identify all affected stakeholders and elicit appropriate requirements.

2. Not identifying all affected stakeholders

It is important to identify all the stakeholders affected by the given business need. If any stakeholder is identified late (or worst not at all!) may lead to incomplete set of requirements and could require a revision to requirements increasing project cost and time.

3. Treating elicitation as a phase

I have found many Business Analysts consider elicitation as a phase after planning (and before requirements analysis). But this is not true. If you think little more deeply, information gets elicited whenever we interact with stakeholders such as sponsor, domain subject matter experts (SMEs), implementation SMEs, users etc.

Elicitation is performed to understand the current state and elicit business requirements. Business requirements are used when eliciting stakeholder, solution and transition requirements. During requirements analysis, we may identify gaps which would require further elicitation. Information is also elicited from the stakeholders about solution performance after implementation of a new solution.

So elicitation is performed on an ongoing basis as long as business analysis work is performed.

4. Not asking probing questions to elicit requirements

Many novice Business Analysts assume stakeholders can proactively provide all the detailed information required for the business analysis work. Such a passive approach can be called requirement gathering but not an elicitation. Such an approach can only lead to identification of shallow requirements.

It is the job of the Business Analyst to extract or draw out the detailed requirements from the minds of the stakeholders. Business Analyst need to ask probing questions to elicit detailed requirements.

5. Not setting stakeholder’s expectations

In your career as a Business Analyst, at times you would find some stakeholder who would state their wants (whims and wishes!) as if they are their needs and expect them to be in the solution. You may find their expectations not only difficult but impossible. If you capture their wants as requirements it would be difficult later on to deliver to their expectations.

With your interpersonal and negotiation skills you need to communicate and set the right expectations.

6. Not using combination of complementary elicitation techniques

I have seen many Business Analysis teams often rely only on one technique such as interviews for elicitation. While interviews is the most effective elicitation technique but its effectiveness depends on the skills of the Business Analyst such as business domain knowledge and ability to ask probing questions.

So, apart from interviews, a Business Analyst should have knowledge of other commonly used fundamental requirements elicitation techniques such as Document Analysis, Observation and Prototyping. While a senior Business Analyst should have knowledge of advanced elicitation techniques such as Brainstorming, Focus Groups, Requirements Workshops and Surveys.

A Business Analyst should be able to understand the given situation and use combination of complementary elicitation techniques.

7. Not eliciting assumptions and constraints

Requirements are often stated (knowingly or unknowingly) based on certain assumptions which are believed to be true at that time. Requirements get impacted if those assumptions are later found to be false.

Constraints are limitations or restrictions (such as regulatory restrictions, budgetary restrictions, time restrictions etc) that restrict potential solutions to requirements. Identified potential solutions may change if there are any changes in the constraints.

If underlying assumptions and constraints are not captured for requirements, it would be difficult to assess impact on requirements if certain assumptions are later found to be false and/ or on potential solutions if constraints are changed.

8. No plan to elicit requirement iteratively

In order to elicit requirements, a Business Analyst contacts a stakeholder and requests their time. Many Business Analysts do not plan to elicit requirements iteratively and assume that stakeholders will provide all the information required for the business analysis work.

However, most of times, stakeholders are not aware why they are being contacted. After their initial meetings, stakeholder will have some idea what is expected out of him/ her. In the subsequent meetings, stakeholder is likely to give bit more detailed information. So, in order to elicit detailed information, Business Analyst needs to plan to elicit requirement iteratively.

9. Not confirming the elicited information

Work of elicitation is not over once Business Analyst is done talking to stakeholders. Business Analyst has to organize the elicited information and send it to the stakeholders for review. The purpose is to check if discussion has been properly documented and confirm the elicited information.

10. Not collaborating with stakeholders to have common understanding of requirements

When the elicited requirements are shared with stakeholders, there can be difference of opinions and conflicts between stakeholders. A Business Analyst has to collaborate, mediate and resolve conflict between stakeholders to reach a common understanding of requirements. Business Analyst should identify the stakeholder’s problems and help to identify solutions to satisfy those problems.

About Author - Trividh Patel, CBAP

Trividh Patel has about 20 years of experience in Business Analysis and Consulting in IT services industry.

Currently, he is working as Facilitator and Mentor - Business Analysis providing self-paced online courses in Business Analysis. Previously, he has worked for leading IT Services companies as Business Architect, Lead/ Sr. Business Analyst, and as IT Project Manager. He has executed several business analysis projects for reputed organizations from USA, UK, Europe, Middle East, Japan and India. He has good track record of leading team of Business Analysts to deliver business analysis projects.

Trividh Patel has done MBA in Systems and Bachelor of Engineering from University of Mumbai (India) and is Certified Business Analysis Professional (CBAP) by International Institute of Business Analysis (IIBA), Canada since March 2012. He is also Certified Six Sigma Black Belt.

For Consulting, Coaching or Guidance on IIBA Certification (or just to connect!), Trividh Patel can be reached on LinkedIn: http://www.linkedin.com/in/trividhpatel-cbap

Product Evaluation Framework for a BA

Ashish Adike — Tue, 20 Oct 2020 22:36:00 GMT

As a Business Analyst, very often we get into a situation where the Project requires multiple IT Products to be evaluated before implementation and might seek Business Analyst’s recommendation for the same. With the ever-growing range of Products in the market and the marketing promotions associated with some of the products, it’s very easy to choose the Product with most features or the most famous one. While there are various benchmarking softwares that measure the IT products from a technical performance perspective, as a Business Analyst, it is our responsibility to make sure that the right product is chosen as we are the ones who know the Business Processes closely and at the same time are equipped to understand the features of a Product that would be well suited to address the Business Requirements. While a Business Analyst may not be the final decision maker, the BA’s analysis definitely impacts the decision-making process. A structured approach to analyze the available Products would help in choosing the best suitable IT product for the Business.

Features: It is recommended to choose a Product that has Features which meet most of the Business Requirements out of the box. Although it’s difficult to find a Product which would satisfy 100% of all the required features, it’s better to choose the one with as little customizations as possible. Customizations would often mean force fitting a Product for a Business Process and may have downstream impact in future. Also, it would involve high maintenance costs to maintain a highly customized Product. As a Business Analyst, we need to provide a Business Process vs Feature mapping for each of the IT Products in question, which would enable the Stake holders to choose the IT Product satisfying the most relevant and critical Business Processes.

User Experience: As a Business Analyst we generally work closely with the Business Users and can gauge the pulse of the Users. It is important that any IT Product chosen provides a good User Experience as it would drive the user adoption and hence the success of the Project. The Business Analyst needs to capitalize the demos provided by the respective IT Products to determine the User Experience levels. Also, many IT Products are available on a free trial version, which can be utilized to get a feel of the Product hands-on before actually implementing the same.

Support: Once an IT Product gets implemented and as the Business Users start adopting it, we see a lot of enhancement requests coming from the Business Users to improve the existing implementation. Also, there might be Bugs in the Product which got missed in the testing process but arise only when the users start using the Product. In order to resolve the issues and implement the enhancement requests, it is critical to have a good post implementation support from the respective IT Product Vendor.

Ease of access: The ease with which Users can access an IT product also plays a vital role in determining the right Product. A Product which can be accessed from any web browser (i.e. Cloud) would always rank better as compared to a desktop based (i.e. on premise). It would even be better if the Product can be accessed from a Mobile device. With the work-from-anywhere concept gaining prominence, the Cloud based, and Mobile enabled Products would see an upward trend in demand.

Product Roadmap: It is important to consider the roadmap the IT Product has planned for implementing various out of box features as that would help us in planning our implementation and make decision on the level of customization that needs to be done during the initial release. The IT Product with promising features suitable to the Business Requirements needs to be given a higher priority as compared to that without a suitable Roadmap.

Although the cost and performance of the IT Product might be considered by the Management, a careful analysis of the IT products with respect to above listed parameters would help the Stake Holders in choosing the right IT Product for long term.

About the Author:

Ashish Adike is a seasoned Business Analyst with more than 8 years of experience in Business Process Analysis, Requirements gathering, Consulting, Solutioning and Project Management. Experienced in working with multiple Business functions – Sales, Marketing, Finance, Operations. Strong research professional with a PGDM focused in Sales and Marketing from Indian Institute of Management, Indore. Awarded team player with excellent learning and adaptability skills.

Does Agile need Architecture to be successful?

EA Learning — Wed, 24 Jan 2018 03:21:00 GMT

On a recent Agile training course, the instructor opened the session by saying “Agile without a plan is just chaos!” I would like to propose that Agile without effective Architecture will eventually lead to chaos, particularly if organisations try to scale their Agile practices without some form of guiding framework.

The fundamental reason for this is that we all operate within constraints, which can be financial, regulatory, technical or customer driven. While Agile practices have traditionally been confined to software development there is a significant push by organisations, particularly at the Enterprise end of the market, to use Agile practices to manage traditional business functions. This new trend is euphemistically referred to as New Ways of Working. The benefits of leveraging Agile practices are numerous, with the fundamental benefit that organisations see Agile practices as a way to deliver improved outcomes for their customers and stakeholders, more efficiently and consistently.

There are numerous case studies citing the achievement of these benefits at a project level, but very few examples (to date) of successful Agile Transformations at Enterprise Scale. Proponents of Agile practices will point to the Spotify Model as proof that Agile Practices can be used to build a $13 billion Enterprise. Which is true, however, they didn’t do it without Architecture. They did it by leveraging Architecture and its practices as an enabler and not a governing framework. The way that Architecture worked within Spotify is quite different to how Architecture currently operates within Traditional Brick and Mortar Enterprises.

It is very hard to find a clear definition of the role of Architecture in Agile. The SAFe (Scaled Agile Framework) framework has done the most to identify the role of Architecture within an Agile environment. As with all things Agile the focus is to create consistent value and Architecture is no different. In SAFe they define two distinct elements of Architecture:

Emergent Design
Intentional Architecture

Emergent Design provides the technical basis for development and the incremental implementation of initiatives. It helps Designers and Architects to be responsive to changing customer/ stakeholder needs to ensure the initiative continually delivers value. At this level, SAFe practitioner’s see Architecture as a collaborative and interactive exercise through which the design element can emerge.

Intentional Architecture is a much more structured approach and more aligned to what many would identify as being traditional Architecture, that is a set of defined and planned Architectural initiatives which will both support and enhance the performance and usability of the initiative. In effect, Intentional Architecture is a clear recognition that we all need to operate within certain constraints such as choice of technology platform, financial budget, etc. If these constraints can be identified and incorporated into the initiative then the probability of the initiative being successful and delivering value is increased.

SAFe practitioners proport that by balancing Emergent Design and Intentionality Agile practices can be scaled to deliver Enterprise level solutions. In Safe, this combination is referred to the Architectural Runway which provides the technical foundation for creating business value. Which is in complete alignment with traditional views of Architecture.

The key to the success of this approach is the level of abstraction at which the balance of Emergent Design and Intentional Architecture occur. The fundamental behaviour that will determine this is collaboration. Architects need to be able to work productively with Agile Teams to provide fast and local support to manage Emergent Design while also helping Agile Teams to appreciate and navigate the constraints defined by the Intentional Architecture. One of the key attributes of Agile Practices is the fact that Agile Teams are encouraged to provide constant feedback to their stakeholders. As emergent designs develop Architects can use this information to adapt and develop the Intentional Architecture to ensure that the overall Architecture of the Enterprise is evolving with the organisation in the medium to long-term.

So does “Agile need Architecture to be Successful?” I would say the better question is “What type of Architecture does Agile need to be successful?” Agile requires Architecture that supports the way the Agile Practices deliver of outcomes (value). The type of Architecture that will do this will be a combination of a nimble reactive style of Architecture supported by a more traditional structured approach to Architecture. The challenge as with many things is to get the mix right!

Written by Scott Comte, General Manager of EA Learning.

To find out more about the EA Learning Business Architecture or Agile training courses please fill out the below form or click here to view our course range.

A Day in the Life of a Business Analyst / Marketing Analyst - Differences, Roles, and Tools

Limor Wainstein — Sun, 07 Jan 2018 11:00:00 GMT

Business analysts typically gather and interpret data from many areas within an organization, finding solutions to business problems and improving business processes with all that data. A business analyst may measure and improve on such disparate things as warehouse efficiency and cloud software implementation.

A marketing analyst, on the other hand, studies quantitative data gathered specifically from a company’s marketing activities, such as customer behavior and social media signals, in order to better optimize marketing strategies.

With the swathes of data collected by Big Data systems and marketing tools at companies of all sizes, marketing analytics is expected to explode. One popular annual marketing study—the 2017 CMO Survey—forecasts a 229 percent increase in marketing analytics spending over the next three years.

In this article, you’ll find out about the differences between a marketing analyst versus a business analyst. You’ll also get informed on the roles and responsibilities, and the types of marketing tools, business intelligence tools, and other software that each must use in their respective jobs.

Roles

Let’s take a look at the common responsibilities and skillsets for these two roles separately.

Business Analyst

Business analysts have much more varied roles than their counterparts in marketing. More specifically, such people are usually responsible for or required to be skilled in different things than marketing analysts for their daily work, including:

Business analysts typically require knowledge of statistics and statistical software such as R. Companies also look for SQL knowledge in their business analysts.
Business analysts can work in projects with accounting, finance, IT, and marketing teams.
Business analysts are responsible for high-level reporting on entire business processes/domains involving multiple data sources.
Business analysts design solutions to problems for the business as a whole, and thus must effectively be able to communicate with many business areas.

Marketing Analyst

Marketing analysts frequently have the following specific skillsets and responsibilities:

Marketing analysts should be good with Excel and understand statistics. They also require excellent knowledge of all marketing tools the business uses.
Marketing analysts work closely with other marketing staff, making sure that all campaigns are tagged and tracked properly.
Marketing analysts build dashboards and reports based on web analytics and other marketing metrics.
Marketing analysts mostly communicate with marketing staff, sales staff, and developers.

Tools

Both marketing analysts and business analysts extensively use a slew of different software platforms in their respective jobs.

Business Analysts

As mentioned, SQL knowledge is much sought-after for business analysts. SQL is a language for managing data held in relational database systems. Business analysts would not require the same level of SQL knowledge as, say, an actuarial analyst, but a fundamental understanding of its capabilities and basic functions is vital.

Additionally, business analysts often use data visualization and business intelligence tools, such as Tableau or SAP BusinessObjects.

Marketing Analysts

Marketing analysts must understand fully all the different marketing tools deployed by the company they work for. This means knowledge of marketing automation and email marketing tools. This source extensively overviews the main marketing tools companies use. Marketers will work with web analytics tools such as Google Analytics and Kissmetrics to get insight into the behavior of prospects. See this wiki providing an overview of the types of marketing tools these professionals use every day.

Differences

Some aspects of both roles lend them well to transferability—marketing analysts are well-placed to become business analysts and vice versa. However, there are important differences that will require a learning curve, including:

Both roles require a good grasp of statistics but the data sources and uses will change. Both roles differ in terms of interpreting what the numbers mean—marketing analysts need to understand numbers in the context of improving marketing strategies while business analysts need to think of streamlining entire business processes from a stakeholder’s perspective.
Marketing analysts will require additional communication skills because a business analyst must communicate with many departments, meaning solely speaking in marketing terms will not suffice.
Business analysts focus on “bottom-line” metrics and KPIs while marketing analysts emphasize metrics indicative of successful marketing strategies and campaigns.
Business analysts are concerned with improving IT architectures as a whole, but marketing analysts just want good marketing tools that work together.

Closing Thoughts

Both roles offer diverse career paths, good salaries, and plenty of opportunities for work. It’s imperative to note that choosing one or the other doesn’t mean you are stuck doing that job forever—working at either of these roles provides valuable skills that you can use if you want to change between them.

Pablo Picasso and Scope Visualization

Paul Crosby — Wed, 07 Sep 2016 14:28:00 GMT

Scope – the last frontier. We are on a mission where no business analyst has gone before. To explore strange new diagrams and to have the project scope clearly understood. Extra credit to those who remember which TV show that was from! Scope and context are the number one reason business expectations about a project are not met, and projects fail.

Let’s face the reality. Projects today are more complicated. In this integrated and connected world of systems long gone are the days of the quick and easy change. Our organization’s architectural diagrams look like the tombs of Egyptian Pharaohs. Symbols and shapes connected by lines that fill the wall of an entire room. Even trying to explain the diagram to someone can take days.

Projects now require more involvement by more people. Our systems and processes are so complex and integrated it’s too difficult for one individual to understand them all. Stakeholders are flung across the globe speaking many different languages. Top it off with organization’s taking on hundreds of projects at the same time. Keeping track of each project’s scope and impacts to the organization are difficult to comprehend. It’s no wonder why understanding the context of a project’s scope is the number one reason why projects fail to deliver value. They lose sight of the project's vision and goals in our complex systems and processes. Everyone is one a different page. We wind up spending a lot of time trying to get stakeholders, sponsors, and team members to have a clear understanding of scope.

So it’s no wonder that scope and context are the number one reasons projects fail. How can you get an entire project team moving in the right direction? Not understanding the scope and context of a project leads to all sorts of time being spent on just figuring out what we are trying to accomplish with a project.

So how do we get everyone on the same page? By that, I mean the same page in the same book!

It’s time to visualize scope. Scope places the boundaries around where the entire project team will work. Bust out that context diagram. Getting a clear common understanding of scope and business expectations leads to better projects that deliver real value. Is that user story a complete representation of the project boundaries or scope? Maybe not. The EPIC or a bunch of user stories combined would be closer to the bulls-eye. A picture is worth a thousand words. Visualization of scope is worth its weight in platinum as it creates the vehicle to ensure a common understanding of the project scope.

Scope visualization isn’t just about a context diagram. That’s certainly a great tool, and I blogged about it previously. Don’t get me wrong – I love my context diagrams. Pushing the envelope a bit, I have used infographics to display project scope in place of context diagrams. In a recent server upgrade project, I was updating the operating systems and consolidating over 1,300 servers. Sticking 1,300 servers on a diagram was an exercise in futility. There just isn’t a big enough piece of paper to display them all. So I pictured things at a higher level. I presented each server farm as a farm – yup cows and red barn with Farmer Joe. The size of the farm was based on the number of servers on that farm. Server farms were in specific locations, so this gave the project team a visual representation of which sites were going to be impacted more heavily. All of this was based on estimates from doing a high-level scan. Remember context is high level.

In each barn was an icon that represented a group of servers. There were three groups: leave it alone, upgrade it and consolidate then retire it. I didn’t have exact numbers or server names at this point, but I knew the servers would be divided into those groups by talking with stakeholders. Servers were put into groups based on our best guess.

In the kickoff meeting, this was a great tool. Sponsor and stakeholders understood in the scope of the project. Yes, they wanted to know more. Everyone wants to know the details, but we were just starting out. Everyone walked out of the room with a pretty good understanding of the scope and estimated size. Many were surprised at the volume of servers in each farm. Overall the infographic did an excellent job of setting the stage for the project visually. All on one PowerPoint slide.

The idea of scope visualization is to present a single page to provide a high-level overview of the changes the project will make to systems, processes, and people. That’s no easy task. Taking the complex and making it simple is powerful. It creates a better shared understanding of the project.

The business wanted a global CRM solution, but all they got were pigeons and index cards. Yeah, that is why context is important.

Context doesn’t just talk about scope – it also sets business expectations about the outcome of the project. It’s important that all throughout the project to keep the communication channels open on what is happening with the scope and how the design is being implemented to meet the scope.

I take the concept of the context diagram a little farther than how most folks typically use a context diagram. You know me always pushing the envelope. Context diagrams usually explain the end state or the outcome of the project. They show the scope of a project outcome.

Building on a good thing, I like to build a context diagram of the current environment at a high level. Even at a high level, I’m often surprised at how differently stakeholders, sponsors, and team members view the current state. It’s a great tool to get everyone on the same page for the starting point. Having everyone on a different page for what we currently have will cause a few issues down the road in understanding the final destination. Knowing where you are starting from is a powerful thing when to explain where you want to end up in the future state.

Taking this concept even a bit further (and perhaps more uncomfortably) into the desired state. Not many projects look at the desire of the stakeholders and sponsors. The desire is stated in the project request form or project charter. The sponsor and stakeholders put together a vision of the expected outcomes in these documents. A context diagram of the project charter or request which elaborates the vision is a powerful thing. It ensures what is being asked for is understood.

Don’t re-invent the wheel. Many times I take the current state diagram and just highlight the areas that are changing. Use color to highlight the add, modify or removes based on the context diagram for the current state. Color visually explains where the changes are visualized to occur.

Now you may think I completely lost my mind at this point. Fear not I’m taking a step even further. I take the context diagram that shows the desired state (based on the project charter or project request) and determines what is feasible. Everybody wants it all but the teleporter to zap you across the globe for a break in Paris hasn’t been built yet. Reality always steps in and dictates what is feasible. Taking the context diagram I will highlight the areas that are NOT feasible. It’s a great way to level set the expectations of the sponsor, stakeholder and project team members.

So when in the project life cycle does all this context stuff happen? Ideally, it should happen before the project starts at a very high level. Wouldn’t it be great to start a project where everyone understood and was in complete agreement about the project outcome? You can bet it would save a lot of time running around trying to get everyone on the same page. Typically, the context is set at the start of the project.

As you move through the project, more and more understanding is acquired. Details need hammering out and there is ALWAYS change to the project. Has anyone ever worked on a project with absolutely zero change? If you have, you are leading a very charmed existence. I’m jealous. Context diagrams can help evaluate how a change would impact the project. So forget about laminating them and hanging them on the wall. They are living breathing documents that will change throughout the life cycle of the project.

The pitfall is that architects and others might expect diagrams that show the smallest of components. Don’t fall into that pit. Your job is to communicate the boundaries clearly but not make it so complicated a rock scientist from NASA can’t figure it out. Detail is important for design but scope context requires things to start at a very high level and be decomposed into more information. Context is simple with enough detail to make it clear.

Break out your inner Pablo Picasso and get creative. Find a way to display context or scope in a visually appealing manner. Color can help bring greater clarity. Highlight areas in different colors to bring focus to them. If a system is risky or substantially impacted by the project scope, highlighting is a technique to denote that risk. Black & White isn’t your friend. Studies have shown that color diagrams – even with a small amount of color – are more memorable.

Check out Bob’s blog for more good stuff on business analysis and sign up for our newsletter today. Bob the BA offers the Badass BA workshop and Enterprise Analysis workshop which covers this technique in more detail.

Things to know before you start your BA career

Bharat Mamtani — Mon, 25 Apr 2016 02:18:00 GMT

Now when I am already a successful BA since many years, I would like to share few moments with everyone.

During my first months as a business analyst, life was filled with a sort of inner turmoil. Even though I had books on how to write requirements documents, had received individual mentoring on putting together use cases, and had a trusted set of templates to follow, there was something uncertain about how the business analysis process would actually unfold.

I found myself making a lot of mistaken assumptions about what to expect, having those assumptions prove to be unfounded, and then needing to find ways to adjust and course correct. Looking back, there is nothing unexpected about my experiences, except that they were unexpected to me at the time.

Knowing that many of you are just getting started, today I am sharing 4 of the things I wish someone had told me when I was just starting out in my business analysis career.

Need to set expectations early and often, and then again and again and again…

As a business analyst, it’s not uncommon to receive too many assignments, tasks that are outside your bailiwick, or unreasonable deadlines. I was surprised to find myself constantly explaining what I was doing, why it was taking so long, and what could be expected of me over the coming weeks, even though I didn’t always know what the next week would look like!

I also found that deadlines would seem reasonable but became overly optimistic when I didn’t hear back from stakeholders in a timely manner, couldn’t get time on the calendar with a critical stakeholder for weeks at a time, or encountered unexpected issues.

I learned to continually clarify my role, communicate about what would be done when, and seek feedback to be sure I was meeting expectations.

Getting information could be a little painful

Early on in my career, I naively expected unlimited access to stakeholders and their unhindered involvement in and passion about my projects.

The reality was much different. My stakeholders had multiple projects, conflicting priorities, and too much to do. Even when my project was important to them, it could still be difficult to get the information I needed in a timely manner.

Over my career, I learned to be a bit of a squeaky wheel – a very polite, diplomatic, and conscientious one – but squeaky nonetheless. My projects started to move more smoothly and I met my deadlines with less angst.

Although being the requirements author, you aren’t the requirements owner.

I love to write and I love to write requirements. But I could get so caught up in writing and documenting and modeling that I would take on more ownership than was prudent. This would lead to a lack of buy-in from critical stakeholders, which could translate to unexpected changes late in the project.

The reality is that we absolutely need stakeholders to take ownership of the content going into the requirements document, even as we author that document on their behalf. And yes, they are likely to resist reading, reviewing, and providing feedback on requirements.

I learned that providing early, incomplete drafts that were clearly imperfect would help stakeholders see that they could add a lot of information and clarity into the requirements. I also learned to be very specific about the status of any given deliverable when sending it out, and equally specific about what I was asking of my stakeholders of this document at this time.

Dealing with issues professionally would take a new kind of finesse

I’ve always been a proactive person and a bit of a whistle-blower. When a new issue surfaced, I would signal the alarm, rally the troops, and facilitate a problem solving meeting.

However, discovering requirements is a gradual process of gaining clarity and minimizing ambiguity. At a certain point in time, every requirement was once an issue. Business analysis surfaces so many issues that you can’t possibly resolve all of them immediately.

With experience, I learned to blow the whistle more softly, keeping everyone informed about what was surfacing, but not unnecessarily alarmed. To keep the requirements process moving forward, I also learned to take ownership of the issues that surfaced inside of the requirements, and make more decisions about how to resolve issues and which options to choose or recommend.

Now that you know what to expect

Now that you know what to expect, perhaps you won’t be as caught off-guard as I was during your first days as a business analyst!

Happy Analysis !!!

You Must Question Requests from the Business

Adrian M. — Wed, 07 Jan 2015 12:52:00 GMT

A while back, I was reading a Computerworld - Singapore article on Business Intelligence and embedded in it was a small, but significant, truth about the business analyst role.

The article points out that a common mistake made by many organizations is to treat the business analyst as a request taker. That is - if the business division asks for a change in the process (or requirements, for that matter) the business analyst is supposed to just do it. In other words, they expect the business analyst to be a "yes man" (or woman).

Many folks tend to forget that the word "analyst" is actually part of the titles of the "Business Analyst" and "Systems Analyst" roles. One of they key responsibilities of the business analyst is to analyze the information received and question that information if it does not make sense.

There can be nothing worse than an organization paying top dollar for qualified business and systems analyst only to treat them as note takers or technical writers.

One of the key values that a business analyst brings to the table is the ability to innovate... the ability to ask "Why?"

The other day - I was reviewing a new set of requirements from the business side and noticed one of them which did not make any business sense.

So I dared to question it...

When I question requests from the business I tend to use a very simple approach:

Why?
Why?
Why?

In this particular case, the answer I got was "Because Mr. X said so!"

What? Because one person said so, it doesn't make it so!

Along with every new requirement and change in business process there must be a justification and clear rationale for the request. If it is not clear that the effort will improve the bottom line - then question it, question it, question it!

As a business analyst you need to make sure that somebody (it doesn’t always have to be you) has analyzed the situation and determined that a change in process or system is needed for one of the following reasons:

it reduced operating costs,
it increases productivity (makes money),
it meets regulatory requirements.

I realize that there are other, more subjective, reasons to make modifications such as increased usability of a product, look and feel requirements, etc. Those types of reasons need to be treated with caution because it is hard to objectively quantify their impact to the bottom line.

What are my motives?

... if you question requirements: What are your motives?

After years and years in this profession - this is something I do without even thinking about it - a matter of habit. But after a little bit of introspection here are some of the reasons why I question business requests:

From a pure business perspective, I want to make sure that the change in process or system improves the bottom line. From a sense of preservation I want the organization I work for to be in business for a long, long time.

Because they hired me to do so... I am being paid for my ability to think and solve problems not for my request taking skills. If that was my goal - I would have become a waiter (no disrespect for waiters intended).

Because deep down in my gut I can't stand designing or asking the developers to implement a change in the system which does not make business sense. Such features are bound to be changed again in the future and are a waist of everybody’s money, time, and effort.

Please note that I am not advocating that you overtly question every single request from the business. If you do that, you'll find your way out the door very quickly.

But you should analyze in your mind every requirement to make sure it makes business sense (at least from your perspective).

Use your better judgment and focus on the requirements with the biggest problems.

If you manage and lead business analysts then you must ensure that you get commitment from upper management on the role, responsibility, and authority your analysts must have. Then turn around and empower your team. Make sure they understand that they are allowed to and must question those business requirements (with tact - of course) which are suspect.

Do you question requirements? When? How?

Adrian

BABOK v2 - End-to-end data flow diagram analysis can highlight issues

Alan — Thu, 10 Jul 2014 01:20:00 GMT

As part of preparation to sit the IIBA CBAP exam, I wanted a one page summary of the overall BABOK flow. The first step of creating a summary matrix showing a derived master list of documents (e.g. Inputs + Outputs) versus the process that creates or uses it was interesting, but not entirely helpful.

By using the matrix to create an indicative data flow type diagram, that helped to better understand the overall end-to-end process documented in the BABOK.
Note: Clear stakeholder information was not available so a Business Process type Model was not possible.

The data flow type visualization technique is very useful:
1. It is an additional visual means of communicating complex information for people who struggle with understanding just text.
2. It quickly shows the flow of information between the various processes
3. The data flow diagramming conventions help to highlight issues. E.g. No clear sources or uses of specific deliverables, redundant and reverse flows etc.

This is also timely given the review of the Draft BABOK v3 material that has been requested and that closes on July 11th.

Brainstorming: A Powerful Tool in Business Analysis

Frank Pipolo — Tue, 01 Apr 2014 04:53:00 GMT

(Image credit: http://www.pinterest.com/pin/14918242487402982/)

Tired of holding those long and boring meetings with your analysts and stakeholders to encourage them to come up with new ideas and strategies for your business? It seems more of drudgery than a productive exercise when you find yourself lecturing your team for hours on end to perform and deliver within deadlines. There’s a high chance that your staff doesn’t exactly look forward to such “pep talk” meets either and probably suppress their yawns as you go on and on about developing the business, waiting to unleash them once you turn your back to them.

If ‘boring,’ ‘drag’ and ‘dissociative’ are the adjectives you would use to describe your meetings, then there’s obviously something else you need to be doing that proves to be fun, engaging and interactive. You might want to consider giving the brainstorming technique a go to bring in a breath of fresh air at the next meet with your team.

What Is Brainstorming?

The Business Dictionary defines brainstorming as a "Process for generating creative ideas and solutions through intensive and freewheeling group discussion." With this unconventional technique, leaders can encourage their team to think out-of-the-box and come up with some radical ideas/solutions without room for shyness or intimidation. One can never have enough good ideas, hence, this technique is useful in generating several ideas which can be used (or not).

BABOK on Brainstorming

As per ‘A Guide to the Business Analysis Body of Knowledge’ (BABOK), brainstorming is one of the important skills that a business analyst requires to be able to perform tasks competently. Whether it is used to identify your stakeholders or to analyze business processes, BABOK says that brainstorming can help at several stages of a project, especially when finding solutions to problems becomes tough. As per this guide - "The aim of brainstorming is to produce numerous new ideas, and to derive from them themes for further analysis" which makes brainstorming a powerful tool at almost any stage of a project.

(Image credit: http://farm3.staticflickr.com/2805/9029594967_26e0a36e3d_o.jpg)

5 Main Benefits of Brainstorming

Diverse Ideas

There are always a couple of members in all teams who take their time in coming out of their shell or are just not used to thinking beyond the set patterns. Brainstorming is a great technique for getting the less involved or quieter members to open up their imagination, think creatively and become participative. Such situations can be avoided though. Care needs to be taken in putting together a group of diverse participants as each one can bring a unique idea to the table, depending on their background. Hence, brainstorming can bring about a broad spectrum of different ideas and expertise which other methods would probably not be able to do.

Covers All Aspects

Since it is almost impossible for an analyst to pinpoint every single influential factor during discovery or other stages of a project, brainstorming takes some of the research pressure off the analyst’s shoulders. It also makes other stakeholders take up a degree of ownership of the project’s initiatives and activities, thereby making them accountable for its success/failure too.

No Inhibitions

More often than not, junior employees tend to be withdrawn around their seniors and refrain from presenting their ideas, no matter how good they are, due to the fear of a backlash. This reluctance to speak up in front of seniors can be overcome through brainstorming sessions as everyone would be considered as an equal with a shared goal and common expectations, thereby eliminating the hierarchical differences among the participants.

(Image credit: http://farm9.staticflickr.com/8180/8046572524_d0c6f19944_z.jpg)

Team Building

Brainstorming is be a fun and effective way of team building as it brings managers, stakeholders, analysts and other employees together on a common platform with each one of them contributing towards the same solution. The best part of this is that as they arrive at one, it makes everyone feel that they’ve contributed to it and generates a bond between the participants. It also serves as a reminder to them that they are creative people with lots of varied ideas to offer.

No Fear of Rejection

In a brainstorming session, there is no ‘right’ or ‘wrong’ so the fear of rejection can be eliminated from the participant’s mind. Certain ideas that might come up but are found to be unsuitable can be kept aside for later consideration or for another project as it can lead to more possibilities while dealing with a problem. For business analysts, it is important to be able to work in an environment where their ideas are respected and the environment is neutral.

To Conclude

If facilitated well, a brainstorming session can bring to fore a plethora of ideas, strategies, information and excitement in the team. For this method to work best, the facilitator needs to build a healthy and safe environment to foster creativity and eradicate scope for bullying and infighting. It is always better to prepare and plan beforehand and have a set of ground rules related to focusing on the problem, being fair and respectful of other’s opinions and building on the ideas of teammates.

By Frank Pipolo

Frank Pipolo is a 20-year professional executive and writer for WCI Communities, a Florida lifestyle community developer and luxury homebuilder, catering to move-up, second-home and active adult homebuyers.

A view of Business Architecture

Richard Skidmore — Sun, 10 Mar 2013 07:11:00 GMT

Just to pass some time recently, I was reading a dictionary (like you do) and I came across the following definitions of architecture:

The art and science of designing and superintending the erection of buildings and similar structures
A style of building or structure
Buildings or structures collectively
The structure or design of anything

So, I got to thinking about these, particularly the last one, and came to the following conclusion - you would not be a very good architect if you didn't understand how buildings are structured and how builders work.

So it seems sensible to conclude that you wouldn't be very useful as an architect in the world of:

data architecture, if you didn't understand data modelling and databases
applications architecture, if you didn't understand software construction and integration
infrastructure architecture, if you didn't understand technology and communications

Therefore, it must be a fundamental requirement for a Business Architect to understand business and the jigsaw of elements that need to fit together to make the entire picture. If I want to understand the business architecture, I need to appreciate the business motivations, business models and business capabilities, plus the people and processes that bind all these individual elements together to deliver value to customers and other stakeholders.

While any business architecture needs to be consistent with, and coordinated with, technical architectures, it is important to understand that it is a different type of architecture. It has clear requirements when it is being constructed. And, it requires a unique blend of skills and competencies to develop it. Business architecture is not just an afterthought of the technical and solution architecture world.

Many business analysts and business managers are becoming involved in business architecture. In developing their knowledge and skills, it is important that the focus is on business understanding if they are to understand the underlying concepts, interconnections and impacts needed for this rapidly expanding discipline to succeed.

In our current world, the pace of change in technology is significant. However, it is also true that with the advent of innovative ways of working, new ways of structuring organisations, streamlined processes and a work force with different motivations and aspirations, we need to consider the architectural considerations and aspirations of the business in addition to those related to the technology. This way, outcomes of real value can be achieved with minimum, or at the very least, controlled, impact to our organisations. It really is the only sustainable way forward.

More blogs can be found here...

The Role of the Requirements Analyst in Driving Specialized Development Teams to Success

Seilevel — Sun, 27 Feb 2011 15:11:00 GMT

I am working on a project where Development teams are divided into specialized areas called Centers of Competence. For example, one team works on Customer data, another team on Product data and validation, another works with the Shopping Cart, another with Checkout and so on. Requirements are gathered within each of these Centers of Competence and handed off to Development for implementation.

The above approach works very well for modular functionality that is specific to a Center of Competence. For example, features specific to Customer Create are usually handled within the Customer Center of Competence and do not impact any of the other teams. But when Customer data flows from one team to another to be used further downstream for pricing, taxation, product segmentation and so on, the modular structure of requirements definition and development breaks down.

This is where the Requirements Analyst plays a crucial role in ensuring that proper functionality is developed. The key techniques we have used to ensure requirements flow across the modular functionality boundaries are as below.

1. Identify all development teams impacted by a requirement or feature request. For example, some specific Customer data may need to be captured to ensure proper pricing and taxation. These requirements will likely originate within those specific Centers of Competence, but will be developed by a different team. So, the analyst creating the requirements will clearly identify the impacted teams other than just his or her own Center of Competence.
2. Communicate clearly to impacted development teams the functionality they need to develop to support requirements in a specific Center of Competence.
3. Get estimates of time to develop, test and deploy from the other impacted teams. This is tracked as a separate task that must be completed prior to requirements being signed off for a release.
4. Conduct cross functional development and requirements meetings so that all impacted teams clearly understand the functionality that needs to be developed.
5. Define clearly the interfaces through which data and messages flow from one sub-system to another. Document any specific data requirements necessitated to support these interfaces.
6. Ensure that the test teams understand the implications for both unit testing and feature testing. There are typically two test teams to deal with. One test team works with a Center of Competence and the other is the global team that deals with the entire application.

All of the above tasks are managed, facilitated and executed by the Requirements Analyst. A good grasp of the overall application, a thorough understanding of data flow, an excellent working relationship with different teams and top notch facilitation skills are keys to success.
Good Requirements professionals managing both their individual areas and coordinating across boundaries are key to the success of the Center of Competence method of dividing and managing Development teams.

Square pegs, round holes - why non-funcs are really not stories

FergalMcGovern — Fri, 17 Dec 2010 21:11:00 GMT

I've been blogging lately about a couple of topics pertaining to 'agile' methods. Along those lines, I wanted to consider one suggested practice that I think is worth reflecting on, that is; the treatment of NFRs (non-functional requirements) as stories.

Let's draw back for a moment. Regardless of process approach, be it traditional or agile, poor treatment of NFRs is one of the highest risk areas in IT delivery. For anyone who has been involved in even a half-way serious type of project, lack of adequate NFR consideration will royally bite you in the bum. In my experience, it is probably the single biggest cause of lost sleep, likely I suspect accounting for the highest rate of ulcers for project & program managers. This applies to stakeholders at all levels, from project managers to executives. Executives as they realise in horror that the $70 million integration project due to go into production in 2 months time is behind and is not scaling according to plan and the business is looking for a release date or that the production system is down periodically for long spells due to scaling issues.

Many stressful roads lead back to NFRs and if the NFR horse has bolted on your project, get ready for some serious stress. That said, let me get back to the point of this post, NFRs as stories.

So, I'd like to challenge one of the sacred cows for some in the agile community; namely that 'everything is a story', including NFRs.

A number of blog posts argue for representing NFRs as stories, including this one. Not everyone in the agile community agrees. The excellent Scott Selhurst blog is a notable example of extremely balanced thinking in that regard. Tom and kai Gilb have a lot to say on the matter here irrespective of whether you're in traditional or agile settings or a mix.

Let's get a definition or two out there, so we're on the same page. Firstly what is an NFR? I will take the definition I first spotted in the 'HP Fusion' process oh about 18 or so years ago, that is we have basically two types of NFRs; Qualities and Constraints. Qualities are generally very clearly measurable and represent things like performance, uptime, data load etc, the classic 'ilities'. Qualities will tend to be associated with strands of functionality or with the system as a whole. Constraints tend to be exactly that, statements of constraint, for instance 'we must support IE 6' (at VisibleThread this particular one pains me considering the variations on service pack OS etc. but as we do have customers on IE 6 we need to satisfy this constraint). An example of a second constraint is: 'Must have a legal disclaimer on every page of the web interface' or 'we must code in Java on JDK version x.y'

You may not agree with the qualities or constraint delineation or have differing views but that's fine, work with me, whatever you choose to call them, most people agree that both styles of NFR exist, regardless of your definition or terminology.

Let me offer a few reasons for why agile analysts & team members should consider avoiding representing NFRs as stories.

Communication: NFRs often have a heavier impact than stories on core design foundations. Ask any tech architect or design lead for war stories on challenged projects they know and you are highly likely to be able to attribute the issue to lack of ability to satisfy one or more NFR as it's root cause. Therefore the act of calling out NFRs as something that is not a story is of immense value from a communication standpoint. As an architect seeing a clear delineation of NFRs (particularly the qualities) from stories helps identify incompleteness.
Cross-cutting scope: NFRs tend to come in two broad 'namespaces', those that apply universally across the project and those that may be associated with 1 or more strands of functionality, (a story in Agile-land). Handling both types of NFRs as stories does not easily allow us to map 1 NFR to multiple stories
Elicitation: NFRs are by their nature, the most difficult class of requirements to elicit. Having explicit categorization and expectation that not only will they exist, but that they are measurable and verifiable forces serious questions to be addressed upfront in iteration-0. By forcing a clarification of measures early in the process around NFRs such as security or scalability, key design and architecture inputs may adjust trajectory
Quality type NFRs are assertions with properties: NFRs are not functional in nature, stories are a functional artifact. Whilst it can be a useful device to use a story persona as a way to drive elicitation of NFRs, in normal complex systems where you need to put in multiple additional associated attributes; boundary values, max, min, mean, load etc., a tabular format tends to be more comfortable for people to read & document.
Testing: Having 1 NFR, particularly Quality oriented NFRs, represented in tabular fashion with each row outlining testable measures for instance, leads to a better ability to conduct test planning. It also means that we can incrementally knock off specific rows as part of particular sprints, yet have the more general NFR in place so it's pervasive and front of mind. Even the best intentioned team members may forget the NFR obligation unless it's kept front of mind.
NFR Lifecycle: Non-trivial NFRs in many cases can affect multiple sprints and have a life-cycle that lasts far longer than a 2 week sprint. Artificially closing them and re-opening them to suit sprint management is not following a principle I try to stick with, that of 'common sense'.

Finally, the agile manifesto really says nothing about NFRs having to be represented as stories. That particular idea is really a vestige of specific agile methods. The true spirit of agile is as much about common sense and 'fit for purpose' as anything else. So, don't be too afraid to stand up and say no to NFRs as stories.

Of course, if you find that NFRs as stories work for your context, excellent. It's just that in my experience, it's really pushing a square peg into a round hole, when we could just as easily fit a square peg into a square hole!

Business Process Analysis (BPA) for the Masses -- Is It Real?

Derek Weeks — Fri, 03 Sep 2010 16:55:00 GMT

This Summer, Gartner produced a research paper entitled "BPA for the Masses: Is it Real?". The paper discusses the increasing popularity of business process modeling tools that can be used by business people. Gartner's position is that the business people have the greatest understanding of their process and can now be equipped with tools that enable them to produce process models very quickly.

Rather than shutting the business users out of the process modeling exercise, they can now be engaged from the beginning. Gartner comments that involving business people in the process modeling exercise helped support the business analyst's efforts to help business and IT understand the process and its related analysis better.

I found the paper interesting and wanted to know if others agreed. Should we place a business process analysis (BPA) tool in the hands of a business user?

When I asked some of my industry peers, I received the following response from Dan Darnell at Waltman, Weinberg & Reis:

“I designed and taught BPMN training focused on our ‘business people’ at QualChoice a few years ago. In my experience, non-IT, non-Analyst folk adapted well and ‘got’ the concepts. I don't understand why it should be surprising or unusual for business-side people to understand and use BPMN or, in general, BPM.

The business side should, or MUST, be involved in the process modeling exercise. Their involvement provides great benefit, and they should be given tools to document their processes themselves. IT, PMO, or similar organizations should not set themselves up as the exclusive provider of formal modeling work - it is not in the company's best interest. My experience was that the business side can model their own processes, and with the proper tools, their work can be integrated into the corporate model.”

Would you agree? Does giving a BPA tool to a business person help you? What has been your experience?

Additionally, Gartner recommends that companies avoid an initial step of buying a BPM suite or an expensive BPA tool. As they see more and more adoption of business process modeling as a responsibility of the business unit or a business service group, they see more businesses investing in low-cost, business-oriented, more accessible modeling tools. They provide many tool examples, but say that Visio clearly dominates.

Would you or have you put Visio in the hands of your business users?

Gartner states, “There are two primary reasons why BPA for the masses will become "real." One is the superior results in achieving true business performance improvement, and the other is the much-broader potential audience that can enable fuller collaboration.”

Do you see BPA for the Masses becoming real in your organization? I believe it only makes sense. The businesses know their process best, but have difficultly describing it or reaching consensus on the details…we have all seen this in discovery exercises. But, I believe there is great value in having business people collaborate with business and process analysts in building the process model while using a common tool. Involving the business helps improve their understanding of the process, their awareness of its complexity and potential problems, and their motivation to improve the process moving forward.

I’d like to hear what you think after you read the paper. For a free copy of the Gartner paper, go to: http://www.global360.com/download/bpa-report/

Planning for Uncertainty

Marc Thibault — Tue, 13 Jul 2010 01:21:00 GMT

The probability that a project will succeed is different for different cost and time targets. There isn't a single right answer to "How long will it take?" or "How much will it cost?" There are a whole bunch of answers, each with its own probability of being right.

The conventional techniques for planning projects only give us one answer—and it's wrong; it's invariably optimistic. Optimism is a good thing as an attitude, but we don't want it in our estimates.

Worse, it usurps management authority to decide how much risk to accept in the target. Impossible goals and missed targets are bad for morale; poor morale leads to lower productivity and trouble retaining good staff. With better information, we can choose more realistic targets and hit them more often.

Effective planning and estimating tools should give us an accurate picture of the relationship between targets and the probabilities of meeting those targets. This is information we can use; if we know what shape the odds are, we can take action to improve the odds or hedge them. We can identify and address problems sooner.

Generally accepted techniques for project planning and estimating don't give us the information we need to do that. Calibrated estimators, good models, probability management and Monte Carlo simulation do.

Measuring the Success of Training Activities

Jarett Hailes — Sun, 10 Jan 2010 17:14:00 GMT

I am in charge of a relatively big training effort for a project (approximately 45 live training sessions in 10 weeks, as well as online training opportunities) to assist with the deployment of a new piece of software. The live training alone will involve over 450 people and will be quite in depth and hands on. Training often plays a critical role in the successful adoption of a new product. Without the proper knowledge of how to effectively use a system, clients can become frustrated, ambivalent or hostile to the change that’s occurring, which can ultimately affect the success of the change.

As a result effective training methods are essential to ensure the ultimate success of the product and the project from which the product was spawned. But how can we determine whether the training was useful, relevant, and appropriate for the given audience? Like any other part of a project or initiative, we’d like to have some accountability on the quality of work product. As a result it is important to come up with ways of measuring how successful your training activities are.

While surveys of trainees and the like can help measure the perceived quality of the training itself, on its own such information does not provide us with a true measure of the success of the training process. You need to map the output of the training to its end goals and from there develop measures that will provide an additional level of understanding as to the quality of the training.

Establish Your Outcomes

First, you need to establish your target outcomes, the end results that you foresee as a result of the training activities. Typically I start with qualitative outcome descriptions. For my project, we want to ensure that clients understand how to use the software well and that they can operate the software independently (i.e. no need to ask for help). We also want to ensure that clients realize how they can use the information available to them through the system to resolve data conflicts with each other rather than having to go through a third party. Lastly, we want to reduce the need for a third party monitoring group to have to contact clients and enforce data resolution and processing activities.

Define Your Measures

Once you have your outcomes, you need to develop ways to measure these outcomes. These must be quantifiable results that you can use to accurately demonstrate whether an outcome was met or not. For example, we could use the number of calls and e-mails to the Help desk regarding the product as a measure for how well clients understand the software once the training is deployed. We can also measure the number of times the third party is contacted to resolve a data issue between clients who work in different organizations. Lastly we can count the number of times the third party must contact clients in order for data conflicts to be resolved.

If the training is related to an existing set of processes, you would ideally use measures for which you already have (or can gather prior to) the implementation of the product/solution. This way you can have data not only post-implementation but also pre-implementation and analyze the impact of the product and the training.

Create Goals for Each Measure

Once your measures are in place, come up with target goals for each measure. If you have pre-deployment data, your goals can be about trending rather than absolute figures (for instance, you could set a goal for a 20% reduction in Help desk calls regarding process X instead of saying your goal is to have less than 200 calls regarding process X).

These goals should be evaluated by the relevant stakeholders, approved by the project sponsor and become part of the project’s success criteria.

Some Considerations

If you’re implementing a product that is designed to improve an existing process you probably have some measures and targets for the productivity of the process itself once the product is deployed (e.g. increase order taking throughput per hour by 50%). For these measures, training is only one of several factors going into the end result and cannot be easily removed to analyze the success of training on its own.

However, you could perform some basic ‘A/B’ tests with a limited subset of clients if you wish to determine how much of an impact training has on the product’s overall success. Train one group of clients as per usual and then train another group with either a different set of training materials, style, etc. or not at all. Assuming you control for other relevant factors that may impact the end result (e.g. level of experience of clients, demographics of clients, etc.) this can be an extremely useful to determine how important training was to the overall success of the project.

If not all of your clients have access to the same type or level of training try and segregate their data so you don’t make erroneous conclusions about the success of your training activities.

Deploying a new product, process, or system into the organization is only as effective as the individuals who implement the change. Making sure that training aligns with the end objectives and can be measured to determine its utility is an important aspect of the overall project’s outcomes.

Jarett Hailes
Larimar Consulting Inc.
http://www.larimarconsulting.com

How effective (or necessary) is a CBAP certificate for job searching?

Jason N — Tue, 15 Dec 2009 19:03:00 GMT

Hello Everyone!

I am new to this community blog, and I am interested in learning more about CBAP certification as it relates to my job search.

In brief, I was employed with a company for 14 years before being downsized in a mass complany layoff last year. Before the layoff, my title over my last 5 years was a Business Systems Analyst. I wrote and managed business/functional requirements, revised BRDs, did system testing, and served as a single point of contact between the client, end user, and IT teams.

In my job search, a lot of the BA positions that I've seen posted require experience in XML, HTML, or some other type of programming/coding experience I currently do not have.

That said, does anyone have any opinion of, direct experience, or comments about the Certified Business Analysis Professional (CBAP) certification program authorized through the International Institute of Business Analysis (IIBA)?

Any comments would be appreciated. Thanks

Video: Get things done with Autofocus

Craig Brown — Mon, 20 Jul 2009 13:29:00 GMT

This video offers a great way to manage your task list. Check it out and consider how it can help you stay on top of your work.